Computing platforms may include heterogeneous processors such as a central processing unit (CPU) and a graphics processing unit (GPU), symmetric and asymmetric processors. The class instances (or objects) may reside in a first memory associated with a first side (e.g., CPU) of a CPU-GPU platform. The second side (GPU side) may not be enabled to invoke the objects and the associated member functions that reside in a first memory associated with the first side (CPU side) of the CPU-GPU platform. Also, the first side may not be enabled to invoke the objects and the associated member functions that reside in a second memory on the second side (GPU side). As the class instances or objects are stored in different address spaces, the existing communication mechanisms may merely allow one-way communication between the heterogeneous processors (CPU and the GPU) to invoke the class instance and the associated virtual functions.
Such one-way communication approach prevents a natural functionality partitioning of the class instances between the heterogeneous processors. An object may comprise throughput oriented member functions and some scalar member functions. For example, a scene class in a game application may have rendering functions that may be suited for the GPU and may also comprise physics and artificial intelligence (AI) functions that may be suited for execution on a CPU. With the current one-way communication mechanism, there typically has to be two different scene classes comprising CPU (physics and AI, in the above example) member functions and GPU (GPU suited rendering functions) member functions, respectively. Having two different scene classes one for the CPU and other for the GPU may require the data to be copied back and forth between the two scene classes.